home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / graphics / chs_ultd.lzh / CHS_ULTD.500 / ANLEITNG / CHAOS_2.TXT < prev   
Text File  |  1992-09-27  |  50KB  |  1,316 lines
  1.  
  2.  
  3.  
  4.  
  5. Teil V
  6.  
  7.  
  8. Dateiformate
  9.  
  10.  
  11.  
  12. An sich sollte es selbstverständlich sein, dass eine Programmdokumentation auch eine Be-
  13. schreibung der verwendeten Dateiformate enthält. Wie so vieles ist es das nicht, was mich
  14. aber nicht hindern soll, hier mit gutem Beispiel voranzugehen.
  15.  
  16.  
  17.  
  18. 1    CHAOSultd-Bilder
  19.  
  20.  
  21. CHAOSultd verwendet für Bilder ein eigenes Format34
  22. Eine Bilddatei besteht aus einem Header, der Farbtabelle, den Parametern, zusätzlichen
  23. Parametern und den Bilddaten, wobei letztere immer gepackt werden, auch dann, wenn sie
  24. dadurch länger werden35.
  25. Der Header sieht (als C-Struktur) folgendermassen aus:
  26.  
  27.  
  28. typedef struct
  29. -
  30. /* id's */
  31. char chaos_id[8]; /* CHSultd5 */
  32. char frac_id[8];
  33. /* grösse, planes und colors */
  34. unsigned int size_x;
  35. unsigned int size_y;
  36. unsigned int planes;
  37. unsigned int colors;
  38. /* zus. parameter */
  39. int lastline;
  40. int last_flag;
  41. int xor_offset;
  42. /* länge der folgenden daten */
  43. long par_len;
  44. long xpar_len;
  45. long pic_len;
  46. /* coltab in long */
  47. /* parameter */
  48. /* zus. parameter */
  49. /* bilddaten */
  50. " FRAC_HEAD;
  51.  
  52.  
  53. chaos_id ist eine Kennung, die die Zeichen CHSultd5 beinhalten muss. frac_id ist eine wei-
  54. tere Kennung, die die Berechnungsroutine, die für das Bild verantwortlich ist, kennzeichnet.
  55. ____________________________________34
  56.     Wozu Standartformate verwenden, wenn man auch eigene definieren kann?
  57.   Aber im Ernst: die verschiedenen Bildgrössen und die Verwaltung der Parameter liessen mir ei*
  58.  *n spezielles
  59. Format sinnvoll erscheinen und wenn man sowieso ein eigenes Format verwendet, ist es auch schon*
  60.  * egal, wie
  61. speziell dieses Format dann ist (denkbar wäre höchstens noch ein GEM-Image-Format gewesen, mi*
  62.  *t einem
  63. erweiterten Header; vielleicht führe ich das mal als alternatives Format ein).
  64.   35das ist kein Scherz, das kann wirklich passieren, die Daten werden aber nicht nennenswert l*
  65.  *änger
  66.  
  67.  
  68.  
  69.                                            45
  70.  
  71.  
  72.  
  73.  
  74. size_x, size_y, planes und colors legen die Bildgrösse, die Anzahl der Bitebenen und die
  75. Zahl der Farben fest. Die Bildgrösse ist - unabhängig davon, ob und wieweit das Bild schon
  76. berechnet wurde - die Grösse des fertig berechneten Bildes.
  77. lastline gibt an, ob das Bild fertig ist oder nicht. Ist lastline 0, so gibt es gar keine
  78. Bilddaten, -1 bedeutet, dass das Bild fertig berechnet ist. Andernfalls gibt lastline die
  79. Anzahl der berechneten und gespeicherten Zeilen an, aber nur falls das unterste Bit in
  80. last_flag gesetzt ist36. Ist dieses Bit gelöscht, so ist für lastline6= 0 stets das gesammte
  81. Bild gespeichert.
  82. xor_offset ist für das Packen der Daten von Bedeutung und wird gleich erklärt; par_len,
  83. xpar_len und pic_len gibt die Länge der drei Datenblöcke an. Die Parameter und zus.
  84. Parameter sind natürlich Bildtypabhängig, bleiben also die Bilddaten.
  85. Im Farbmodus werden zunächst die Bitplanes, die im Screen-Format ja wortweise hinter-
  86. einanderstehen getrennt, d.h. es kommt erst die ganze Bitplane 0, dann 1 usw. (man hat
  87. also gewissermassen ein GEM-Standartformat, wobei die Grösse des Blockes durch size_x
  88. und size_y festgelegt ist).
  89. Dann werden die Bilddaten von hinten mit dem xor_offset mit sich selbst via xor ver-
  90. knüpft. Der Offset entspricht im Allgemeinen einer oder mehreren Bildschirmzeilen. Da-
  91. durch entsteht ein Bild, dessen Zeilen (ausser der ersten) immer nur die Differenz zur
  92. darüberliegenden Zeile beinhalten und das deshalb i.a. besser zu packen ist. Ist xor_offset
  93. 0 so entfällt die Xor-Verknüpfung. Um die Xor-Verknüpfung beim Laden rückgängig zu
  94. machen muss man die Daten erneut via xor miteinander verknüpfen, diesmal allerdings von
  95. vorne.
  96. Anschliessend werden die Bilddaten im Stad-Format gepackt und gespeichert.
  97. Das heisst die gepackten Daten beginnen mit den drei Bytes Kennbyte, Packbyte und Spe-
  98. zialbyte, anschliessend folgen die gepackten Graphikdaten, wobei folgende Kodierungen An-
  99. wendung finden:
  100. Das Kennbyte und das nachfolgende Byte n bedeuten, dass das Packbyte n+1 mal zusam-
  101. mengefasst wurde.
  102. Das Spezialbyte und die beiden nachfolgenden Bytes a und n bedeuten, dass das Byte a n+1
  103. mal zusammengefasst wurde.
  104. Alle anderen Bytes müssen so wie sie in der Datei stehen in das Bild übernommen werden.
  105.  
  106.  
  107.  
  108. 2    Filme
  109.  
  110.  
  111. Film-Dateien haben sich gegenüber FRACTAL Version 4.1 (und 4.3) nicht geändert.
  112. Sie bestehen aus dem Header 'film', der (als 2 Byte Integer abgelegten) Anzahl verschie-
  113. dener Bilder sowie der Anzahl der Bilder im Film. Es folgen die Anzeigeoptionen (eine
  114. SHOW_OPTS-Struktur), daran schliessen sich die Informationen über die im Film enthal-
  115. tenen Bilder an. Und zwar für jedes Bild Dateipfad, Name und Dateiextension, jeweils als
  116. nullterminierter String (unter diesen Dateinamen werden die Bilder beim Einladen eines
  117. Filmes gesucht). Deshalb ist es auch nötig, dass die Bilder beim Speichern des Filmes ge-
  118. speichert sind, FRACTAL könnte sonst höchstens raten, wohin man die Bilder abspeichern
  119. wird. Dateipfade können (seit FRACTAL V4.3) relativ sein, sie beginnen dann nicht mit
  120. einem Laufwerk. In diesem Fall ist der Pfad relativ zum Verzeichnis der Filmdatei zu ver-
  121. stehen.
  122. ____________________________________36
  123.     die anderen Bits sind reserviert
  124.  
  125.  
  126.  
  127.                                            46
  128.  
  129.  
  130.  
  131.  
  132. Zuletzt folgt eine Liste mit der Reihenfolge der Bilder im Film, wobei sich die Nummern (1
  133. Byte Integer) auf die Reihenfolge der Dateinamen beziehen.
  134. Filmdateien dürfen nicht länger als 32000 Bytes sein.
  135.  
  136.  
  137.  
  138. 3    Einstellungen
  139.  
  140.  
  141. Die Einstellungsdateien will ich hier nicht im Detail erläutern, da sie sicher nicht sonderlich
  142. interessant sind.
  143. Eventuell doch von Interesse ist allerdings der prinzipielle Aufbau dieser Dateien, die ja
  144. nicht nur die Voreinstellungen von CHAOSultd selbst, sondern auch die der diversen Be-
  145. rechungsroutinen - letztere in nicht festgelegter Reihenfolge und womöglich wechselnder
  146. Anzahl.
  147. Realisiert wird dies durch eine Block-Struktur. Jeder Block beginnt mit einem 12 Byte
  148. langen Header: die ersten 8 Byte erhalten eine Kennung (CHAOSultd verwendet für seine
  149. Einstellungen CHSultd5, für die Berechnungsroutinen wird die gleiche Kennung verwendet
  150. wie in Bilddateien. Es folgt als Langwort (4 Byte) die Länge der folgenden Daten. Ansch-
  151. liessend kommen die Einstellungsdaten sebler, deren Inhalt von den Berechnungsroutinen
  152. abhängt; die CHAOSultd-Einstellungen bestehen aus einer CHS_SET-Struktur, die in der
  153. Headerdatei XCOMMON.H definiert ist.
  154.  
  155.  
  156.  
  157.                                            47
  158.  
  159.  
  160.  
  161.  
  162. Teil VI
  163.  
  164.  
  165. die  Schnittstelle  für  externe  Routinen
  166.  
  167.  
  168.  
  169. Die folgenden Erläuterungen sind nur für Programmierer bestimmt, die eigene Berechnungs-
  170. routinen für Bilder irgendeiner Art schreiben wollen.
  171. Aus technischen Gründen ist es nicht ratsam dies in einer anderen Sprache als C37 und
  172. vermutlich auch da wiederum nur in Pure C (bzw. Turbo C) zu versuchen. Wie weit andere
  173. C-Compiler mit den Parameterübergabe-Konventionen von Turbo/Pure C zurecht kommen
  174. weiss ich nicht (vermutlich eher nicht, Turbo/Pure C übergibt Parameter auch in Registern).
  175. Man sei sich auch darüber im Klaren, dass die eigentliche Berechnungsroutine (jedenfalls
  176. solange man sie nicht sehr aufwendig optimiert) meist nur einen kleinen Teil der nötigen
  177. Routinen darstellt, insbesondere sollte man in der Lage sein, mit GEM-Dialogboxen umzu-
  178. gehen. Ich setze im folgenden stets vorraus, dass Interessenten in C programmieren können,
  179. insbesondere den Umgang mit Strukturen beherrschen, ebenso die Programmierung von
  180. GEM-Programmen.
  181. Wie aber werden externe Routinen überhaupt eingebunden? Und welches Format muss die
  182. erzeugte XCH-Datei haben?
  183. Um die zweite Frage zuerst zu beantworten: bei der XCH-Datei handelt es sich um eine
  184. normale Programm-Datei, die aber keinen Startup-Code besitzt. Erzeugen kann man eine
  185. solche Datei mit Pure C, indem man in der Projektdatei einfach den Startup-Code weglässt
  186. (man kann das so erzeugte Programm natürlich nicht vom Desktop aus ausführen).
  187. Das Programm enthält auch keine Funktion main, eingebunden wird es vielmehr so, dass
  188. die erste Funktion der Source-Datei nach dem Laden und Relozieren aufgerufen wi